Every ERP-MES integration project eventually runs into the same wall, usually a few weeks in, when someone from finance asks why the quantities in SAP don’t match what actually happened on the floor. The answer is almost never a bug. It’s that “work order” means two genuinely different things depending on which system you’re standing in, and nobody sat down early enough to reconcile the two. With SAP’s ECC end-of-mainstream-support timeline pushing plants toward S/4HANA and tools like SAP Digital Manufacturing or Siemens Opcenter, this confusion is surfacing constantly. It’s worth understanding from the ground up, because it’s the foundation everything else in the integration gets built on.
What ERP means by “work order”
In ERP — SAP, Oracle, Infor, whatever — a work order (or production order, or process order, the terminology varies) is a planning object. It says: build this quantity of this material, by this date, consuming these components, at this cost center, according to this bill of material and this routing. It exists to answer financial and logistical questions. Can we promise this to the customer? What will it cost? What do we need to procure? When it’s created, nothing physical has happened yet. It’s a commitment, not an event.
Critically, the ERP work order is coarse-grained. It typically represents a batch or lot — say, 500 units of a finished good — and it tracks status in broad strokes: Created, Released, In Process, Delivered, Closed, Technically Complete. ERP doesn’t usually care, structurally, whether those 500 units were made in one continuous run or across three shifts on two different lines with an unplanned tool change in the middle. It wants the inputs consumed, the outputs confirmed, and the costs settled.
What MES means by “dispatch list”
A dispatch list is what the ERP work order turns into once it needs to actually happen on a physical machine, in a physical sequence, with a physical operator. This is the ISA-95 boundary in action: ERP owns Level 4 business planning, MES owns Level 3 production operations, and the dispatch list is the artifact that lives on the Level 3 side.
The dispatch list breaks the ERP order into operations — the individual routing steps — and sequences them against real constraints: which machines are available, which operators are qualified, what’s already queued, what tooling is mounted, what maintenance windows exist. It’s not one static thing; it’s continuously re-sequenced as reality changes. A 500-unit order might spawn a dispatch list entry per operation per machine, and those entries carry their own execution-level states: Queued, Setup, Running, Paused, Waiting-on-Material, Complete.
This is the first thing to internalize: the ERP work order is a single record with a handful of coarse states. The MES-side execution of that same order is a graph of operations, resources, and events, each with its own lifecycle. They are related, but they are not the same object, and that mismatch is where drift starts.
Status states don’t map one-to-one
ERP’s “In Process” might correspond to a dispatch list entry that’s paused for a shift change, or one where the first of five operations just started, or one where four of five operations are done and the fifth is stuck waiting on a fixture. ERP has no native vocabulary for that granularity. Whoever builds the integration has to decide, explicitly, what MES-level state changes actually trigger an ERP status update — and what gets absorbed silently at the MES layer. Get this mapping wrong and ERP will report an order as “in process” for a day after the floor considers it finished, or “released” when material has already been consumed against it.
Splits and merges
Real production splits work orders constantly. A machine goes down mid-run and the remaining quantity gets rerouted to a second machine. A lot fails inspection partway through and gets segregated. An operator combines two small orders onto one setup to save changeover time. MES has to represent these splits and merges at the execution level — often creating new dispatch entries or sub-lots with their own genealogy — while the ERP order underneath, in the simplest integrations, doesn’t split at all. It just eventually receives a quantity confirmation that doesn’t obviously correspond to any single physical run. If your MES can split and merge freely but your integration only sends ERP a final aggregated number, you’ve lost the traceability that regulated industries in particular need to reconstruct later.
Partial completions
ERP generally expects a work order to move toward a single completion. MES lives in partial completions constantly — 320 of 500 units finished on first shift, the rest tomorrow; 480 good, 20 scrapped, 500 accounted for. Each partial completion is a real event that ideally should post to ERP as it happens, both for accurate WIP visibility and for materials planning downstream. Many plants instead batch these up and post once at order close, which is easier to build but means ERP’s picture of in-process inventory is stale for the life of the order. That’s a design choice, and it should be made deliberately, not by default.
Backflush timing: the quiet source of most reconciliation headaches
Backflushing is the practice of deducting component material from inventory automatically, based on the bill of material, at the moment a finished quantity is confirmed — rather than requiring an operator to manually issue every component. It’s efficient, and it’s also where a huge share of inventory discrepancies originate.
The question is: backflush timing relative to what, exactly? Some configurations backflush at each operation completion. Others backflush only at final order completion. Others backflush at a designated “backflush point” partway through the routing — common in electronics and discrete assembly, where a component is consumed early but you don’t want to wait until the whole order finishes to relieve inventory. If MES is driving partial completions and ERP’s backflush logic is configured for order-level completion, component consumption in the ERP inventory ledger will lag real physical consumption on the floor by however long the order stays open. In a plant running long work orders across multiple shifts, that lag can be substantial, and it shows up as phantom inventory that “should” be there according to SAP but was physically consumed days ago.
A practical checklist for spotting the divergence
- Pull an open work order in ERP and its corresponding dispatch list state in MES right now. Do the quantities match? If not, can you explain the gap without guessing?
- Find out exactly which MES events trigger an ERP status transition, and which ones are absorbed at the MES layer with no ERP visibility at all.
- Ask what happens, mechanically, when MES splits an order across two machines. Does ERP see two operations against one order, or does it just see a delayed single confirmation?
- Check your backflush configuration against your actual completion pattern. If MES reports partial completions throughout a shift but backflush only fires at order close, your live inventory numbers are fiction for the duration of every open order.
- Trace one scrapped unit from the machine where it was rejected to where it lands in the ERP quantity ledger. If you can’t follow that path cleanly, your genealogy has a gap that will eventually matter — in an audit, a recall, or just a very confusing Tuesday.
None of this is a criticism of any particular platform. SAP’s order structures, Opcenter’s dispatch model, and every other serious MES all support fine-grained execution tracking — the divergence comes from how a specific plant configures the boundary between them, not from a limitation in the tools themselves. The lesson is that the ERP-MES integration project isn’t really an integration project. It’s a modeling project, and the model you’re reconciling is the work order’s entire lifecycle, state by state, split by split, from the moment it’s released to the moment its last gram of scrap gets accounted for.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
